SEB Trading Station

Historical context

SEB launched Trading Station in 1997 to give corporate customers access to financial markets online. It combined currency trading with live rates, market news and financial analysis. By September 1999, SEB was expanding the service into interest-rate and futures trading.

1997

Trading Station launched

700

Corporate FX clients in September 1999

2,000+

Users worldwide in September 2000

These figures describe the Trading Station service as a whole. SEB’s 1999 announcement also reported that the service handled about 20% of its corporate-client currency trading in Sweden. SEB’s 2000 announcement reported usage by 1,000 companies.

The business challenge

Corporate traders needed current prices to make decisions. The existing application struggled with the required concurrency and could not continuously update prices in the browser. Manual refresh left traders responsible for checking whether the information they were using was current.

The imposed stack

Commercial agreements constrained the technology choices. The team had to establish infrastructure while learning parts of an immature enterprise Java stack and coordinating delivery with an external partner.

The architecture decisions

Deliver updates to the browser

The team treated the browser as a client in a distributed application. Custom communication and JavaScript let it receive and display changing prices without requiring a page refresh. The implementation predated the WebSocket standard.

Distribute market data through messaging

IBM enterprise messaging gave backend services a common way to distribute market updates. The browser-facing application could receive the information it needed without a separate integration with each market data source.

Limit dependence on emerging frameworks

The team used only the EJB capabilities required for delivery. Timely market information was the business requirement. EJB, the application server and the browser communication mechanism were implementation choices.

The reported result

Up to 100 continuously updated market prices for an individual user.

The firsthand project account reports this result for an individual user. It provides no concurrent-load figures or measured latency. For a trader, the functional change was direct. Prices could update on screen without manual refresh.

The practical lesson

The team had to work within a mandated stack, but it could still decide how information moved through the system. That distinction is central to Policy vs Detail. Timely market information was the policy. The products and protocols were details the team could evaluate against it.

When designing a similar system, define how fresh the data must be when the user acts. Then test the full path from the source to the screen under representative concurrent load.